Process control systems and methods provide a way for improving efficiency, reliability, profitability, quality and safety in a process/product manufacturing environment. Such process control systems and methods can be used for automation, monitoring and control of devices and applications in a wide array of industrial applications for many industry segments, such as textiles, glass, pulp and paper, mining, building, power, sugar, food and beverage, oil and gas, steel, water and wastewater, chemicals, etc.
Conventional process control systems and methods generally operate with a plurality of field devices positioned at various locations on, e.g., a 4–20 mA analog network. These field devices include measurement and control devices (such as temperature sensors, pressure sensors, flow rate sensors, control valves, switches, etc., or combinations thereof). Recently, a number of protocols have been introduced which provide a digital alternative to conventional control systems and methods, and which utilize “smart” field devices. These “smart” field devices can provide the same functionality as the conventional devices listed above, and may additionally include one or more microprocessors, one or more memories, and/or other components incorporated therein. Such smart field devices can be communicatively coupled to each other and/or to a central processor using an open smart communications protocol. Such protocol (e.g. Foundation® Fieldbus protocol) has been widely used in manufacturing and process plants. A number of such protocols have been developed for non-process control environments, such as automobile manufacturing or building automation, and then later adapted to be used for process control. Some of the more widely used fieldbus protocols include Hart®, Profibus®, Foundation® Fieldbus, Controller Area Network protocols, etc.
Fieldbus process control systems and methods may also utilize a controller that is communicatively coupled to each of the smart field devices using an open “smart” communications protocol, and a server communicatively coupled to the controller using, for example, an Ethernet connection. Moreover, this controller may include a processor, and can receive data from each of the “smart” field devices. Such “smart” field devices each preferably include a processor for performing certain functions thereon, without the need to use the central host for performing such functions. The amount of processing to be executed by the centralized host generally depends on the type of the control application and the protocol used.
A smart fieldbus device, as configured by a software configuration tool, may be programmed to execute function blocks. A function block can provide fundamental automation functions that are performed by the process control application. In essence, the function blocks are software models which can define the behavior of the process control system. More particularly, the function block may be a software logic unit which processes input parameters according to a specified algorithm technique and an internal set of control parameters, and generates resulting output parameters that are available for use within the same function block application and/or by other function block applications. The input parameters of one function block may be linked to the output parameters of one or more other function blocks on the fieldbus network. The execution of each function block can be scheduled. After the function block is executed using the corresponding input values, its outputs are updated and then published on the network, where they can be subscribed by inputs of other function blocks using this information. These linked function blocks may reside either inside the same field device or in different devices on the network.
Three different types of function blocks are generally used in the fieldbus applications, e.g., Resource Blocks, Function Blocks, and Transducer Blocks. For example, the Resource Blocks define parameters that pertain to the entire application process inside a device (e.g., manufacturing ID, device type, etc.). The Function Blocks encapsulate control functions (e.g., PID controller, analog input, etc.). The Transducer Blocks represent an interface to sensors such as temperature, pressure and flow sensors.
Each function block in the system can be identified by a unique tag which is generally assigned by the user. The parameters of each function block can be represented by object descriptions that define how the parameters are communicated on the fieldbus network. Thus, many parameters in the system are likely uniquely identified by their reference to their block tag and parameter name or, alternatively, by their reference to their block tag and parameter relative index (the ordinal index that represents the offset of the parameter in the whole list of parameters).
Each fieldbus device likely has a Resource Block and at least one Function Block with input and/or output parameters that link to other function blocks, either in the same device or in separate devices by using the fieldbus. Each input/output parameter generally includes a particular value portion and a particular status portion. The status portion of each parameter includes information regarding the reliability of the data contained in the input/output parameter, and instructs the receiving function block as to whether the reliability of contained data is acceptable, uncertain or unacceptable. In addition, a Function Block Application Process (“FBAP”) can specify the handling of control modes, alarms, events, trend reports and views. These features comply with the Foundation® specification in order for the device to be considered interoperable at a User Layer.
Distribution of control to the field devices can be performed by synchronizing the execution of the function block, and transmitting the function block parameters on the fieldbus network. Such functions, along with the publication of the “time of day” to the devices, an automatic switch over to a redundant time publisher, an automatic assignment of device addresses, and a search for parameter names or “tags” on the fieldbus can generally be handled by System Management and/or Network Management.
A control strategy may be generated through an interconnection of the various function blocks contained in the field devices. The control strategy may also be modified without any hardware changes, thus providing another level of flexibility. Function blocks and control strategies are further described in the Foundation® Fieldbus and Profibus® fieldbus specifications, both of which are incorporated herein by reference.
The configuration of a fieldbus control strategy, however, can be an extremely complex task. A large application can involve hundreds or even thousands of function blocks. Such a large fieldbus network configuration may have several associated problems. The manual typing of block tags can be extremely repetitive, time consuming and cumbersome. Additionally, the manual entry of block tag names may result in errors. It may also be a waste of resources for a trained technician to spend a significant amount of time entering the tag names.
Further, conventional software configurators are usually complex and unwieldy due to the open nature of known fieldbus network protocols. Such configurators are designed to accommodate devices produced by a number of different vendors which may provide a wide variety of functionality. Many of these configurators (in an effort to simplify their design) generally rely on a scheme in which the configuration is loaded directly from the field devices. However, it may be advantageous to provide for the configuration to be completed and modified off-line as well.
Additionally, because of the high level of complexity of fieldbus control strategies, prior art software configurators may need a highly trained user with substantial fieldbus experience to perform all configuration creation and modification functions.
Currently, there exists no logic arrangement, system and method which can automatically generate function block tags based on the device tag for the device containing the function block. Such logic arrangement, system and method would facilitate a more efficient configuration procedure for a fieldbus network and devices. Additionally, there exists no logic arrangement, system and method which can be configured to maintain the consistency of function block tags in such scheme, whereby the function block may be moved from one device to another, and therefore (due to this deficiency) the tag would therefore need to be manually changed to remain consistent with the tag naming scheme. Furthermore, there exists no logic arrangement, system and method which facilitate off-line scheduling of function blocks and network traffic for a fieldbus network while automatically distributing function blocks to the devices.